Tables - 2.61.0

This feature aims at ensuring Hosts retain maximum control over their site. Previously, when editing details of a booking on a locked table, Tables would try to find a better fitting sitting for the party to focus on maximising capacity. However, this could have a negative effect as there was a risk of overbooking tables or moving guests away from their favourite spots. As such, we've introduced new logic to hand that decision-making to the Hosts.

The logic behind this feature is outlined below with examples illustrating how it can be utilised:

SCENARIO 1: [Locked Table] + change in number of attendees:

• 'Locked' table by Tables user

• Number of attendees is changed through the guest portal, external API, Tables App, Host App

  • Expected behaviour:

    • If a table is 'locked' on tables application, then the system shall ignore the check that number of attendees is within or above the minimum and maximum covers limit for that table

    • The 'locked' table remains locked and unchanged

Examples:

1. [Decrease below minimum covers]

1. Booking A with number of attendees: 4 with Table 6 assigned

2. Tables user LOCKS table 6

3. On Guest portal (or external API, tables, events), lead guest (tables user/host app user) decreases number of attendees from 4 to 2

4. System checks - Table 6 status = locked

5. No change in table assigned for the booking - table remains locked

 

2. [Increase above maximum covers]

1. Booking A with number of attendees: 4 with Table 6

2. Tables user LOCKS table 6

3. On external API, tables, events, tables user/host app user increased number of attendees from 4 to 10

4. System checks - Table 6 status = locked

5. No change in table assigned for the booking - table remains locked

SCENARIO 2: [Locked Table] + change of booking time:

• 'Locked' table by Tables user

• Date or time of the booking is changed via external API, Tables App, Host App

• Expected behaviour:

  • If a table is 'locked' on tables application and date, time or turn time of the booking is changed, then the system should check if there is a Table Locked for the new time / date / turn time

    • If yes then Host gets Option to:

      • Accept - Table is double booked (i.e. Table remains locked) and the Host has to manually change either of the bookings

      • Cancel - Current Booking's details (date, time or turn time) aren't changed and are returned to what they were before edits, Table remains locked

      • Move Current Booking - the system finds a new Table for the booking to be moved to; and locks the new Table

    • If no, booking is moved to new date and time; Table remains locked

Example:

1. [Date change]

1. Booking A on 26/06/2023 with Table 6 assigned

2. Tables user LOCKS table 6

3. On Tables / Events a Tables user / Events Host app user changes the date to 27/06/2023

4. System checks - Table 6 status = locked

5. System should check if there is a Booking with a Table Locked for the new date

   • If yes then Host gets a pop-out "Table is already assigned for this time, would you like to proceed?" with options to:

     • Accept

     • Cancel

     • Move Current Booking

   • 5b. If no, booking is moved to new date; Table remains locked.

 

2. [Time change]

1. Booking A at 12:00 with Table 6 assigned

2. Tables user LOCKS table 6

3. On Tables / Events a Tables user / Events Host app user changes the time to 5:00pm

4. System checks - Table 6 status = locked

5. System should check if there is a Booking with a Table Locked for the new time

   • If yes then Host gets a pop-out "Table is already assigned for this time, would you like to proceed?" with options to:

     • Accept

     • Cancel

     • Move Current Booking

   • If no, booking is moved to new time; Table remains locked (solution for overlapping turn times in Scenario C below).

3. [Turn Time change]

1. Booking A at 12:00 with Table 6 assigned with 2 hours of Turn Time

2. Tables user LOCKS table 6

3. On Tables / Events a Tables user / Events Host app user changes the Turn time to 3 hours

4. System checks - Table 6 status = locked

5. System should check if there is a Booking with a Table Locked for the new end-time of the current booking

   • If yes then Host gets a pop-out "Table is already assigned for this time, would you like to proceed?" with options to:

     • Accept - Table is double booked (i.e. Table remains locked) and the Host has to manually change either of the bookings

     • Cancel - Current Booking's time isn't changed and is returned to what it was before edits, Table remains locked

     • Move Current Booking - the system finds a new Table for the booking to be moved to; and locks the new Table

   • If no, booking is moved to new time; Table remains locked.

Because we want hosts to retain maximum control over their site, we decided not to forcibly change users on locked tables even on the fringe scenarios, as showcased below:

• Tables can have sessions, each session can be configured with a different table layout, if I'm assigned to table 1 and locked, then moved to a layout where table 1 doesn't exist, I'm still assigned and locked to that table even though it doesn't exist - This remains for Host to manage, as multiple layouts are beyond the scope of the feature

• Tables can be blocked in advance, e.g. at breakfast I block tables as that's where I put the buffet food, if I'm moved to a timeslot where my locked tables is set to be blocked, I'll still be assigned a blocked tables - This remains for Host to manage, as its within their decision making to ensure correct tables are blocked

Moreover, we have introduced an icon in Events to signify a lock table, so that Hosts do not need to juggle between 2 apps to find that information. Further details of this change are available in the Events 1.61.0 release notes.

This feature builds around providing Hosts with more information about their bookings by introducing new pill payment icons.

Please note - If the Host moves a Locked booking via the 'suggest' button to another table, the table will need to be Locked again - Unless, auto lock setting is active, then it will automatically Lock the table.

As of now Tables only shows how much deposit has been paid but doesn't easily provide info on the outstanding value. This is available in booking's details but not readily there available otherwise, as the user needs to open a new window in order to find out new information.

As seen below here are our old icons for to signify incomplete pre-order and payment, however, it isn't until we open the booking that we can see the £200 actually consists of :

However, with our new feature, we've split up Deposit and Pre-payments, as well as, modified it so that it showcases the amount already paid against the total amount of needed to satisfy the condition: